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ABSTRACT : 

Herein discolosed is a software information reusing system comprising: a 



data base for storing software information; a dialogue display terminal; 
thereby processing the information inputted from the display terminal. 
First retrieval information of the software information is registered as 
data related with a link of a data information related concept. If second 
retrieval information is not in the registered data, it is judged on the 
basis of the link of the related concept whether or not third retrieval 
information related therewith exists. The data base is retrieved on the 
basis of the third retrieval information. As a result, it is possible: to 
form a dictionary data base including a noun dictionary and a synonym 
dictionary for analyzing and generalizing the data object of the 
specification to be newly registered; for a user unacquainted with the 
business knowledge to automatically extract a proper retrieval keyword 
from a retrieval request sentence describing the software coming into the 
mind of the user-; and to judge from the relations between the keyword 
information and the before and behind words whether or not even a 
composed word left either unregistered as one word or unknown is the 
retrieval keyword, if even one of elements composing the composed word is 
found to have the corresponding keyword information. 

17 Claims, 22 Drawing Figures 

US PAT NO: 5,123, 103 : IMAGE AVAILABLE: L3 : 11 of 12 



CLAIMS : 



=> d 13 1,5,11 



I. 5,659,751, Aug. 19, 1997, Apparatus and method for dynamic linking 
computer software components; Andrew G. Heninger, 395/685, 683, 710 
:IimGE AVAILABLE: 

5. 5,553,290, Sep. 3, 1996, Software packaging structure having 
hierarchical replaceable units; Nathaniel Calvert, et al., 395/703; 
364/280, 286, DIG.l; 395/710 : IMAGE AVAILABLE: 

II. 5,123,103, Jun. 16, 1992, Method and system of retrieving program 
specification and linking the specification by concept to retrieval 
request for reusing program parts; Noriko Ohtaki, et al., 707/5; 
364/222.81, 222.82, 225, 225.1, 234, 237.2, 274, 274.1, 274.2, 274.8, 
282.1, 282.4, 283.3, 283.4, 286, DIG.l; 395/703, 710 : IMAGE 
AVAILABLE: 



us PAT NO: 
DATE ISSUED: 
TITLE: 
I^^VENTOR: 

ASSIGNEE: 

APPL-NO: 

DATE FILED: 

FRN-PRIOR: 

INT-CL: 

US-CL-ISSUED: 

US-CL-CURRENT: 



SEARCH-FLD: 
REF-CITED: 

4, 330, 822 
4, 734, 854 
4, 809, 170 
4, 827, 404 
4, 833, 641 
4, 860, 204 
4, 949,253 
4, 956, 773 
4, 974, 160 
5, 005, 119 
5, 084, 813 
5, 101, 491 
5,123,103 



5,261, 100 : IMAGE AVAILABLE: L6: 19 of 20 

Nov. 9, 1993 

Method of software development 
Tsutomu Fujinami, Kawasaki, Japan 
Hirohide Haga, Kyoto, Japan 

Hitachi, Ltd., Tokyo, Japan (foreign corp.) 
07/363, 509 
Jun. 8, 1989 

Japan 63-144526 
:5: G06F 15/40 

395/700, 650, 919, 922; 364/DIG.l, 275.1 
395/703; 364/225.6, 225.8, 234, 236.8, 237.2, 237 
238.3, 243, 243.3, 259.4, 262, 265, 274, 274.2, 
275.1, 286, 286.1, DIG.l; 395/706, 919, 922 
364/200, 900; 395/600, 650, 700, 919, 922 



Jun. 10, 1988 



3, 

274. 3, 



5/19 
3/19 
2/19 
5/19 
5/19 
8/19 
8/19 
9/19 
11/19 
4/19 
1/19 
3/19 
6/1992 



U.S. PATENT DOCUMENTS 
Dodson 
Af shar 

Leblang et al . 
Barstow et al . 
Lerner 

Gendron et al. 
Chigira et al. 
Saito et al . 
Bone et al . 
Rumbaugh et al . 
Ono 

Katzef f 



364/200 
364/200 
364/200 
364/200 
364/900 
364/300 
364/200 
364/200 
364/200 
364/200 
395/1 
395/500 
395/600 



OTHER PUBLICATIONS 
Shi-Kuo Chang, IEEE Software, vol. 4, pp. 29-39, Jan. 1987. 
Interactive Programming Environments, Barstow et al . 1984 pp. 370-413. 
Komiya, et al . , "Automatic Programming by Fabrication of Reusable Program 

Components", Information Processing, vol. 28, No. 10, 1987, pp. 

1329-1345. 
ART-UNIT: 237 
PRIM-EXMR: David L. Clark 

ASST-EXMR: John Loomis 

LEGAL-REP: Fay, Sharpe, Beall, Fagan, Minnich & McKee 



ABSTRACT: 

A program data managing apparatus comprising memories for storing as 
program data a source code, technique data on a process for making the 
source code, and intention data on intention to make the source code; a 
link indicative of the mutual relationship between program data; a 
display for displaying the relationship between the program data using 
the link; a link provided to indicate the relationship between a newly 
developed source code and the original program data from which the new 
source code derives; and a display for displaying the source code 
developed stepwise by that link and the related program data. 
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TEXT: 

Flowcharts and expert systems-what could seem farther apart? 
Flowcharts remind us of punched cards and Fortran, and seem too rigid for 
the relatively unstructured knowledge behind an expert system. On the other 
hand, if you do have a flowchart, why waste time with expert systems 
instead of writing a program from the flowchart? Sometimes, however, this 
unlikely combination is useful because you can use flowcharts for knowledge 
acquisition, and expert-system shells and languages are an easy way to code 
flowcharts into runable software. Also, a flow-chart-based knowledge 
base is easy to change. 

KNOWLEDGE ACQUISITION 
Let*s start with knowledge acquisition". As a knowledge engineer, your 
goal is to extract problem-solving knowledge from the expert for a 
computerized knowledge base. Sometimes the experts have already 
organized the knowledge into a flowchart for their own use. This was the 
case for a patient-management expert system I wrote recently; an 
almost-complete flowchart was available in a technical bulletin for 
doctors . 

Suppose a flowchart isn*t available. For patient management and many 
other potential expert-system applications, the problem solver, whether 
human expert or expert system, gathers information and makes a 
determination using that information. Each problem situation is a dialog 
between the expert and client. As a knowledge engineer, you interview the 
expert, asking questions "What do you do first?"; "What information do you 
look for now?"; "What do you do now?"; "What are the possible situations 
that can occur next?"; "What are the conditions under which these 
situations occur?" Using these questions, we can lead the expert through 
one scenario, then go back to a choice point and take another branch, 
continuing the process until all choices are explored. 

As we conduct the interview in this form, we record each dialog as a 
path in an emerging flowchart, adding actions, branches, and edges to the 
flowchart as needed. with each successive dialog. The flowchart neatly 
summarizes the information so that the expert can inspect it for 
completeness. In addition, each phase of the dialog consists of reporting 
actions and decisions in a sequence similar to how they occur in practice; 
this makes the form in which knowledge is reported similar to the form in 
which it is used. 

ENCODING FLOWCHARTS 

That a flowchart existed for the patient-management problem was the 
good part; the bad part was that it grew to contain more than 60 boxes. 
Compared to recommended software metrics, many expert-provided 
flowcharts are too big or contain loops that don't map easily into 
structured code. Tasks performed by organizations, such as adding a new 
book to a library, also have complex flowcharts, especially when we try to 
capture procedures in practice rather than as formally defined. 

While it*s always possible to transform a flowchart into one 
containing only if-then-else branches, begin-end blocks, and while loops, 
this restructuring has several disadvantages: As descriptions of what 
should be done, the restructured flowcharts are often harder for the expert 



to understand. This n^es it harder for the expert to^cntribute to the 
development and main^^nce of the system. Also, you ^| make mistakes 
transforming the ori^ial flowchart into structured coae . Finally, small 
changes to the original flowchart can require major changes to the 
restructured one. For these reasons, we want to encode the expert's 
flowchart in a straightforward, recognizable way into an expert system. 
Prolog and rule-based shells are ideal for this task. 

To demonstrate some techniques for turning flowcharts into rules, 
we'll use the example in Figure 1, which is illustrative only. If we create 
one rule for each path from the top of the flowchart to the conclusion, we 
get the rule set shown in Listing 1. The if part of each rule contains the 
logical conditions that must be satisfied to follow a particular path to a 
conclusion box; that conclusion is in the then part of the rule. 

As the path length from the top to the bottom of the flowchart 
increases, this logic-based approach becomes increasingly unwieldy, because 
the hypothesis contains one condition for each edge in the path. In 
addition, the number of paths flowing through an interior region of the 
flowchart increases, so a change in the flowchart affects a large number of 
rules. 

We can overcome this problem by using a state variable. Its value, 
called the current state, tells us where in the flowchart we are at the 
moment. To represent the current state, we'll assign a unique name to each 
box in the flowchart and use these names as possible values of the state 
variable; in Figure 1, the box names appear just outside the box. Listing 2 
shows rules for the flowchart rewritten using state variables. Now the 
complexity of each rule does not change, no matter how long or looping the 
paths through the flowchart become-although the chance for unexpected 
computational paths does increase as the flowchart becomes messier. 

Now suppose that the expert finds that the original flowchart is not 
quite right. Each change to a path in the flowchart causes only one rule to 
change in the knowledge base, when using the state variables in 
the rules. In contrast, if we used conditions on paths, many rules would 
change. Likewise, there is no single, simple change in a structured program 
that mirrors a one-edge change in an underlying messy flowchart. Encoding 
the expert's original flowchart using state variables minimizes the work in 
responding to changes requested by the expert. It also helps experts 
understand how the expert system corresponds to their own knowledge. 

Listing 3 shows Listing 1 in Prolog. The process predicate holds the 
expert system rules, and the other predicates run the rules. The when 
predicate tries to prove that its question argument has the answer 
specified in its second argument; consider moves the system to a new state; 
and conclude makes a recommendation to the user. A good strategy for when 
is backward chaining, with asking the user as a backup source of 
information; for the implementation details see "A Portable Engine, " AI 
Expert, jan. 1990. The resulting system uses forward chaining at the top 
level to execute a specified, overall problem-solving strategy, while 
leaving the details to be figured out by backward chaining. Global forward 
chaining with local backward chaining seems to represent a good compromise 
between the unpredictability of pure backward chaining and the detailed 
programming required for pure forward chaining; some shells, such as Exsys, 
of fer' this hybrid strategy as an option. 

The basic structure of the Prolog flowchart program also handles 
multiple answer questions, such as "Which of the Ten Commandments has the 
candidate violated?" If we let when return a list of answers and make 
consider put each corresponding next state in the database, the program 
will eventually get around to each branch we chose. 

As the flowchart gets bigger, your expert system might slow down. 
This happens if all the process rules are stored in a single linear list 
searched from the top each time a state is processed. Some Prologs like 
Quintus) index clauses on the first argument, automatically 
eliminating this problem. If your Prolog doesn't do this, you can program 
the technique yourself (Listing 4) . First reprogram initialize to record 
the body of each process clause under the state in its head. Then modify 
process to try each rule of the current state in turn. 

HELPING THE EXPERT 



By looking at rules derived from our flowchj^t, we see that a 

knowledge base of th^Miype is really just a table in^Pich 

each row represents o^ rule that corresponds to one line in the flowchart. 
An individual row is fully specified when we provide: 

* The current state that activates the rule 

* Tests that have to be satisfied for the rule to apply 

* Actions to be performed once the test is satisfied 

* The new current state after performing the actions 

* Whether additional rules can apply at the current state 
Knowing that this is all we need for the top level of our expert 

system, we can say to the expert: First list all the situations or 
problem-solving steps that occur when you work on problems that the expert 
system should do (column I of the table) . Then for each step you listed, 
list the questions you would ask and the answers you might receive (column 
2) . Now, for each partially filled-in row, complete the table. To complete 
a knowledge base, we would also have to ask an expert for 

conditions that imply the tests in the table so the finished system can do 
local backward chaining. 

I hypothesize that filling in such a table is relatively easy for 
experts compared to writing if-then rules with complete logical conditions 
for tests and actions. This is because experts usually have years of 
practice, and they can replay in their minds what they do step by step. 
They also know and can identify situations where tests and actions ought to 
be considered, which is what we ask them to do in filling in the table. 

On the other hand, writing complete logical conditions for rules is 
like explaining expertise to a novice; for both a novice and a computer, 
you can't assume that they will be able to fill in obvious details you 
leave out. By asking for information in a form that allows experts to 
replay their experience, and by coding with states the experts provide, we 
can construct, at least for interview-and-decide expert systems, a 
knowledge base that any domain expert can understand. 

Rodger Knaus is a principal of instant Recall, a Bethesda, Md. firm 
specializing in the development of Prolog-based applications. 

Listing 1. Rules using logical conditions. 

If: Initial test is {negative} then: No further evaluation is needed 

If: Initial test is {positive} and: Biopsy contains {no abnormality} 
then: Monitor again in 6 months 

If: Initial test is {positive} and: Biopsy contains {abnormal cells) 
then: Evaluate treatment options 

Listing 2. Rules using state variables. 

If: {STATE} = "Initial test" and: Initial test is (negative} then: No 
further evaluation is needed 

If: {STATE} = "Initial test" 

If: Initial test is {positive} then: [STATE] := "Perform biopsy" 
If: {STATE} = "Perform biopsy" and: Biopsy contains {abnormal cells} 
then: {STATE} := Evaluate treatment options 

If: {STATE} := "Perform biopsy" and: Biopsy contains (no abnormality} 
then: Monitor again in 6 months 

Listing 3. Rules using state variables 
machine : 

initialize, 
repeat, 

single_state . 
single_state : 

retract ( current_state ( STATE)), !, 
process ( STATE ), fail. 
single_state : 

message ($Computation concluded. $) . 
consider ( STATE) : 

asserta( current_state ( STATE)), 
initialize : 

consider { $Initial test$ ) . 
process ( $Initial testS ) : 

when( $Initial test is$ , $negative$ ) , !, 
conclude { $No further evaluation is needed$ ). 



process ( $Initi^^test$ ) : 

when( $In^pfel test$, $positive$) , !, 
consider ( perform biopsy$ ). 
process ( $Perform biopsy$ ) : 

when ( $Biopsy content $, $no abnormal! ty$ 
conclude ( $Monitor again in 6 months$ ) . 
process ( $Perform biopsy$ ) : 

when ( $Biopsy content$, $abnormal cells$ 
consider ( $Evaluate treatment options$ ). 
Listing 4. Indexing rules by state, 
initialize 

consider ( Initial test$ ) . 
clause ( process ( STATE) , BODY ), 
recordz ( STATE, BODYfail. initialize :- !. 
process! STATE ) : 

recorded! STATE, RULE_BODY, _) , 
call ( RULE_BODY ) , ! . 

COPYRIGHT 1992 Miller Freeman Publications 
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ABSTRACT: The unlikely combination of expert systems and flowcharts can be 
useful for developing knowledge bases such as expert system 
shells and languages. While expert systems can be used to gather the 
necessary information to solve a particular problem, flowcharts help to 
summarize the data so that experts can inspect it for thoroughness. The 
expert's flowchart should be encoded using PROLOG and knowledge- 
based shells. The fundamental structure of the PROLOG flowchart 
program handles multiple answer questions. A knowledge base 
developed using expert systems and flowcharts is essentially a table with 
individual rows representing rules that match with individual lines on the 
flowchart. By requesting data in a form that enables experts to replay 
their experience, and by coding with states the experts offer, expert 
system developers can build a knowledge base that all domain 
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ABSTRACT: Metric-based classification trees provide an approach for 
identifying user-specified classes of high-risk software components 
throughout the software lifecycle. Based on measurable attributes of 
software components and processors, this empirically guided approach 
derives models of problematic software components. These models, 
which are represented as classification trees, are used on future systems 
to identify components likely to share the same high-risk properties. 
Example high-risk component properties include being fault-prone, 
change-prone, or effort-prone, or containing certain types of faults. 
Identifying these components allows developers to focus the application of 
specialized techniques and tools for analyzing, testing, and constructing 
software. A validation study using metric data from 16 NASA 
systems showed that the trees had an average classification accuracy of 
79.3 percent for fault-prone and effort-prone components in that 
environment. One fundamental feature of the classification tree generation 
algorithm is the method used for partitioning the metric data values 
into mutually exclusive and exhaustive ranges. This study compares the 
accuracy and the complexity of trees resulting from five techniques for 
partitioning metric data values. The techniques are quartiles, 
octiles, and three methods based on least weight subsequence (LWS-chi) 
analysis, where chi is the upper bound on the number of partitions. The 
LWS-3 and LWS-5 partition techniques resulted in trees with higher accuracy 
{in terms of completeness and consistency) than did quartiles and octiles. 
LWS-3 and LWS-5 trees were not statistically different in terms of 
accuracy, but LWS-3 trees had lower complexity than all other methods in 
terms of the number of unique metrics required. The trees from the 
three LWS methods (LWS-3, LWS-5, and LWS-8) had lower complexity than did 
the trees from quartiles and octiles. In general, the results indicate that 
distribution-sensitive partition techniques that use only relatively few 
partitions, such as the least weight subsequence techniques LWS-3 and 
LWS-5, can increase accuracy and decrease complexity in classification 
trees. Classification analysis techniques, along with other empirically 
based analysis techniques for large-scale software, will be supported 
in the Amadeus measurement and empirical analysis system. (Reprinted 
by permission of the publisher.) 



